The present invention relates generally to transaction processing systems and more particularly to an efficient method for transaction recovery in three-tier applications.
Commonly, human end-users are exposed to many different failures and error situations in systems which are called transaction processing systems (TPS). TPSs are three-tier (client-server-database) systems which allow client applications to perform database transactions. xe2x80x9cClientxe2x80x9d refers to an end-user mode of operation and level of access where requests are made for server processing or database information. As examples of database transactions, there are various reservations systems, such as for airlines, hotels and car rentals, and financial systems, such as banking, credit card, and automated teller machines. In these systems, a customer or sales representative uses a client application at the client level that allows a user to query and update a database. A client interface allows the client application to specify which database to add information to or to update. However, if a failure occurs in either the second tier application server or the third tier database, for example during an update, it is difficult for the client to know whether the update was actually performed or not.
As an example, for an Automated Teller Machine (ATM) failure, it is likely that the ATM customer would need to call the bank to find out whether the transaction was completed properly. This would generate more work for bank employees and create unsatisfied customers and would be very costly in terms of the lost business, reduced productivity, and unsatisfied customers.
Essentially, the client needs to query the database and see if the update has been performed and if it has not, to reissue the update. Even this solution is, however, not failure proof.
First, the system might not know what the values were before the update, and if the update is relative to the old value, the client might not be able to determine whether the initial update was performed or not. For example, if the ATM transaction involved a deposit to an account, the bank employee would have to have information regarding the previous balance and any other deposits and withdrawals that may have occurred to the account around the time of its failure.
Second, another client might have done an update after the first client""s query and failed update. Therefore, the first client will not be able to determine with confidence whether the update was performed or not, requiring the first client would have to guess what to do.
Thus, involving the client in the recovery of a failed request should be avoided to the largest possible extent. Unfortunately, complex commercial database systems and transaction processing systems generally fail to provide client transparency, or the ability to detect and correct problems without human intervention. Rather, it is expected that the failure recovery either be handled by the client or be coded into applications.
Embedding the failure recovery into the application code complicates the application considerably and is error prone.
Implementing error recovery logic is difficult and complex. Client applications as well as application servers currently need to implement error recovery as part of the application specific code. Further, the error recovery logic is not necessarily reusable for any application adhering to the described architecture.
Traditional solutions have centered around devices called xe2x80x9ctransaction coordinatorsxe2x80x9d, which are responsible for coordinating and terminating transactions against one or more databases. The potential for failure in both the coordinator and the databases requires that some recovery information be maintained so that a consistent state can be maintained when recovering after failures. This is necessary so that transactions that were in the process of being terminated when a failure occurred can be completely terminated upon recovery. There are problems with these systems however.
First, traditional systems keep the recovery information in their local disk file on the same machine that runs the transaction coordinator. Maintaining this disk file has a performance cost due to the continual writing of entries to the disk file.
A second problem with maintaining recovery information in local disk files is in emerging three-tier applications. It is desirable for the transaction coordinators to recover as stateless in the middle tier, which means that entries should replicate freely and that it should be possible that a crash can occur on one node and recovery can occur on a different node. Having recovery information in local disk files so hampers that flexibility that the benefits of three-tier applications are lost.
Third, current transaction coordinators do not perform xe2x80x9coutcome determinationxe2x80x9d. xe2x80x9cOutcome determinationxe2x80x9d is when the result of a transaction is needed to make a decision. The coordinators keep recovery information around long enough for consistent recovery by the application server, but the moment that a transaction has completely terminated, whether it""s abort or commit, the information is deleted. In some cases this is too early because the client machines need to know the outcome in order to determine if they are retrying aborted transactions. Using the recovery information can save a system from duplicating its efforts.
The latter two problems have been major long-term obstacles to the wide spread adoption of three-tiered systems.
An answer has long been sought to solve the above problems, but it has also long eluded those skilled in the art.
The present invention provides a three-tiered transaction processing system in which state information maintained in the database tier is used to facilitate recovery of transaction coordinators without the transaction coordinators having to maintain their own recovery information and a method of accessing such state information.
The present invention further provides for a three-tiered transaction processing system in which state information maintained in the database tier is used to facilitate recovery of transaction coordinators without the transaction coordinators having to maintain their own recovery information and a method of accessing such state information while controlling the lifetime of this recovery information; i.e., keeping it around long enough so that client tier will have a consistent view of the world before the information is forgotten. This solves the problem of outcome determination.
The present invention further provides an extension of the XA interface, a standard used by database management systems to control transactions, to also include two additional methods that give access to the set of committed transactions in the database transaction log and the set of prepared transactions in the transaction log of the database management system. The present invention exploits the fact that the transaction log contains entries about committed and prepared transactions already. This solves the problem that the database management system forgets about those entries once transactions are committed.
The present invention further provides for a three-tiered transaction processing system that eliminates the performance cost associated with the writing of recovery information to the server.
The present invention further provides for a three-tiered transaction processing system with stateless recovery in the middle tier. If one server crashes, the recovery information is stored in the database and recovery can take place on a different server node.